Writing Your SRS – Getting Off to a Good Start

April 1999 Identifying Requirements – How Will I Know One When I See One? Requirements begin their lives when first elicited from customers or users. Elicitation may occur using any of a variety of techniques such as interviews, brainstorming, prototyping, questionnaires, and quality function deployment or techniques. Typically, requirements start out abstractly, e.g., “I need a system that controls elevators.” As exploration continues, they become more specific, more detailed, and less ambiguous—they split and recombine in new ways (especially when multiple cases exist). Eventually, a set of highly detailed requirements emerges, e.g., “When the ‘up’ button is pressed, the light behind that button illuminates within one second.” Once captured, it is extremely important to maintain traces from each requirement to its more abstract predecessor requirements and to its more detailed successor requirements. Traceability aids in change management and is a fundamental component of quality assurance and sound requirements management. The final, most detailed requirements are contained in a document called a requirements specification. This specification must be communicated and agreed upon by all relevant parties. It serves as the basis for design (it tells designers what the system is supposed to do) and for test (it tells testers what the system is supposed to do). Good requirements specifications exhibit the following characteristics [1]. • Lack of ambiguity – It is unlikely your product will satisfy users’ needs if a requirement has multiple interpretations. • Completeness – Although it may be impossible to know all future requirements for a system, you should at least specify all known requirements. • Consistency – It is impossible to build a system that satisfies all requirements if two requirements are in conflict. • Traces to origins – The source of each requirement should be identified. It may have evolved from the refinement of a more abstract requirement, or it may have come from a specific meeting with a target user. • Absence of design – As long as requirements address external behaviors as viewed by users or by other interfacing systems, they are still requirements regardless of their level of detail. When a requirement attempts to specify the existence of particular subcomponents or algorithms, it is no longer a requirement but rather design information. • Enumerated requirements – Most requirements specifications enhance their readability by including auxiliary types of information that are not requirements. This information includes introductory paragraphs or sentences, summary statements, tables, and glossaries. Actual requirements contained in the document should be somehow easily discernible, whether by unique font, identifying label, or other highlighting. A complete list of principles to adhere to when performing requirements specification appears in Chapter 3 of [2].